Method and apparatus for tracking call processing failure data in a radiotelephone system

ABSTRACT

A system ( 102 ) for monitoring call processing failures in a radiotelephone network ( 100 ) includes a server ( 140 ) coupled with the radiotelephone network and configured to receive call processing failure data. The system further includes a plurality ( 142 ) of clients configured to be coupled to the server on a network ( 144 ) for display and analysis of the call processing failure data. The clients may include a portable client ( 152, 154 ) for remote or wireless access to call processing failure data at the server, permitting troubleshooting and failure analysis in the field. The client computers are preferably Windows-based and provides both analog (AMPS) and digital call processing failure counts.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of application Ser. No. 09/354,049filed Jul. 15, 1999 in the name of Chuyun Wu and commonly assigned withthe present application, which application is incorporated herein in itsentirety by this reference.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the U.S. Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

MICROFICHE APPENDIX

A microfiche appendix of computer program source code is included andcomprises 2 sheets and a total of 114 frames.

The Microfiche Appendix is hereby expressly incorporated herein byreference, and contains material which is subject to copyrightprotection as set forth above.

BACKGROUND OF THE INVENTION

The present invention relates generally to monitoring and control ofwireless telecommunication systems. More particularly, the presentinvention relates to a method and apparatus for tracking call processingfailure data in a radiotelephone system.

Radiotelephone systems are wireless telecommunication systems in which atwo-way radio communication link is established between one or more basestations and a mobile station. As the mobile station moves around thegeographic area covered by the system, the communication is handed offfrom one base station to another. Radiotelephone systems includecellular telephone systems, personal communication systems (PCS),trunked radio systems and others.

Call processing failures occur in radiotelephone systems for a varietyof reasons. Transmission from a local station may be unexpectedlyinterrupted if the mobile station enters a tunnel or loses batterypower. During handoff, communication with the old base station may beterminated before initiation of communication with the new base station.Other reasons exist as well, such as co-channel and adjacent channelinterference.

Many such call processing failures occur randomly. However, a largepercentage of call processing failures may occur due to the same cause.Such a cause might be an otherwise undetected equipment failure. Anothercause might be a break in coverage pattern of the system, where handofffailures occur. If such causes can be detected, they can be correctedand overall system performance improved.

One previous technique for tracking call processing failures uses asoftware program running on a personal computer (PC) coupled to acellular processor of a cellular telephone system. The PC program readsradiotelephone data for call processing failures of an analog phonesystem and provides counts of the failure by type.

While useful, this previous solution has not kept up as cellular systemsexpanded. For example, the PC connects to a port of the cellularprocessor and collects data for a single switch of the cellulartelephone system. Data for other switches in the system are notavailable to that PC. The PC is not portable, but requires a hard-wiredconnection directly to the cellular processor. The former system onlyreads call processing failures in an analog advanced mobile phone system(AMPS), not the digital systems currently being deployed. Only failurecount totals are available. No details on individual call processingfailures can be accessed. Further, only real time data are available.Historical failure data are lost.

Accordingly, there is a need for an improved method and apparatus fortracking call processing failure data in a radiotelephone system.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a radiotelephone system and associatedsystem for monitoring call processing failure data in the radiotelephonesystem;

FIG. 2 is a block diagram of a server for use in the system of FIG. 1;

FIG. 3 is a block diagram of a client for use in the system of FIG. 1;

FIGS. 4-6 are flow diagrams illustrating a method for operating theserver of FIG. 2 in the system of FIG. 1;

FIG. 7 is a flow diagram illustrating a method for operating the clientof FIG. 3 in the system of FIG. 1;

FIG. 8 is a screen view of a client computer;

FIG. 9 is a screen view of detailed call processing failure data for ananalog radiotelephone system; and

FIG. 10 is a screen view of detailed call processing failure data for adigital radiotelephone system.

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENTS OF THEINVENTION

By way of introduction, in one embodiment the present invention providesa Windows-based server/client program that displays call processingfailures in real time. In addition, the embodiment also displaysarchived call processing failure data in history. The embodimentprovides twelve different analog (advanced mobile phone system or AMPS)call processing failure counts and twelve different digital (codedivision multiple access or CDMA or other digital system) callprocessing failure counts with sorting options, detailed display andmobile station search capabilities. All components of the system arecombined in a local area network or wide area network to provideflexible extension and expansion of the system. Any suitable personalcomputer can be used for the client, including portable laptop or othercomputers connected via wireless link to the network. Thus, the presentembodiment uses conventional hardware and takes advantage of advancedcomputer technology to provide a full-featured, user-friendly interfacefor real-time troubleshooting of cellular network systems.

Referring now to the drawing, FIG. 1 shows a block diagram of aradiotelephone system 100 and an associated system 102 for monitoringcall processing failure data in the radiotelephone system 100. In theillustrated embodiment, the radiotelephone system 100 is a cellulartelephone system. However, in alternative embodiments, theradiotelephone system may be a personal communication system (PCS),trunked radio system or other system providing radio communicationsbetween fixed radio stations and mobile radio stations.

In the illustrated embodiment, the radiotelephone system 100 includes aplurality of switches including switch 104, switch 106 and switch 108.Associated with the switch 104 is an operations management platform 110and a plurality of base stations including base station 112, basestation 114 and base station 116. Each base station provides two-waycommunication with mobile stations such as mobile station 118 when themobile station 118 is located in the geographic area served by the basestation. Thus, the base station 112 serves a geographic area 120, thebase station 114 serves a geographic area 122 and the base station 116serves a geographic area 124. In FIG. 1, the geographic areas areillustrated as being hexagonal in nature. In other embodiments, thegeographic areas may have any suitable shape and are generallyoverlapping. As the mobile station 118 moves among geographic areas,two-way communications between the mobile station and base stations arehanded off from base station to base station. High level functions suchas handoff and system control are handled by the switches including theswitch 104. Switch 106 and switch 108 control a similar group of basestations. Depending on the embodiment, each switch may control more than200 base stations and each base station may be in radio communicationwith dozens or hundreds of mobile stations in its associated geographicarea.

As noted, associated with the switch 104 is an operations managementplatform (OMP) 110. Similarly, associated with switch 106 is an OMP 128and associated with the switch 108 is an OMP 130. Each OMP serves as adata interface with its associated switch. In one embodiment, the OMPscomprise computer systems manufactured by Sun MicroSystems and operatingin response to software provided by Lucent Technologies.

In conventional operation, each OMP monitors operation of its associatedswitch and receives data describing every operation performed within theradiotelephone system 100. For example, when a mobile station such asthe mobile station 118 is turned on, the mobile station registers withthe nearest base station, such as the base station 114. The OMP 110detects and records the registration operation. Further, when the mobilestation 118 initiates a phone call, the OMP detects and records theattempt to place a call. Stored data include identification for themobile station 118, the time of day of the call attempt and the calledtelephone number. If the mobile station 118 is moving, handoff from onebase station to another may be necessary. The OMP records all of thecontrol signals between the switch and the base stations involved in thehandoff procedure as well as the control communication between themobile station 118 and the base stations. As a further example, when theuser of the mobile station 118 turns off the mobile station, the mobilestation de-registers with the system before powering off. The OMPfurther records this event. If a call processing failure occurs, the OMP110 records the call processing failure. For example, if the mobilestation 118 moves into a tunnel or a building so that two-way radiocommunication is interrupted and an active call is dropped, the OMPrecords this call processing failure.

By recording all activity in the system associated with the switch, theOMP generates tremendous amount of data. This data may include 100,000records and 30 megabytes per day. The data produced by the OMPs 110,128, 130 is available at each OMP on a real time basis, i.e., as eachevent occurs, and is further archived by storing the data in a suitablestorage medium.

The system 102 for monitoring call processing failure data in theradiotelephone system 100 includes a server 140 and a plurality 142 ofclients linked together by a network 144. The plurality 142 of clientsincludes in one embodiment several client computers which comprise ofpersonal computers (PCs) located on a desktop or in a service facilityaccessible by the network. This includes client 146, client 148 andclient 150. The plurality 142 of clients further includes a dial-upclient 152 which may be connected to the network 144 over a computermodem. Still further, the plurality 142 of clients includes a portableclient 154 which connects to the network 144 using a wireless link. Thewireless link in one example uses cellular digital packet data (CDPD)for wireless communication of digital data. Structure and operation of atypical client computer will be described in further detail below inconjunction with FIG. 3.

The server 140 is coupled to each of the OMPs 110, 128, 130 forreceiving call data from the radiotelephone system 100. The call dataincludes all data provided by the switches 104, 106, 108 through the OMP110, 128, 130. As noted above, this is a very large amount of data andincludes data corresponding to all operations within the radiotelephonesystem 100. The server 140 identifies call processing failure data inthe call data. This may be done, for example, by identifyingcharacteristic patterns in the data, reading record informationassociated with the data or by any suitable method. Further, the server140 organizes the call processing failure data according to call failuretype. Possible types of call failure data will be described furtherbelow. Still further, the server 140 transmits selected call processingfailure data to a client computer in response to a request from theclient computer. The selected call processing failure data aretransmitted over the network 144. If the requesting client computer isportable, the select data may be transmitted using a wireless link, forexample to a portable client computer 154, or using a modem over astandard telephone land line connection to the portable client 152.Still further, the server 140 preferably stores all call processingfailure data as archived data. After filtering unwanted call event datawhich includes, for example data from the OMPs 110, 128, 130 which isnot related to call processing failures, the server 140 stores in anassociated memory the remaining call processing failure data. The server140 transmits the current call processing data in response to a requestfrom the client computer. The current data includes real time data whichis data currently produced by a switch or an OMP in response to acurrent event in the radiotelephone system 100. The server furthertransmits archived data in response to an archived data request from theclient computer. Structure and operation of the server computer 140 willbe described further below in conjunction with FIG. 2.

FIG. 2 is a block diagram of a server 140 for use in the system 102 ofFIG. 1. In FIG. 2, the server 140 includes a central processing unit(CPU) 202, a memory 204, a plurality of switch ports 206 including afirst switch port 208, a second switch port 210 and a third switch port212. The server 140 further includes a plurality of client ports 214including a first client port 216, a second client port 218, a thirdclient port 222, one or more modem ports 222 and one or more wirelessports 224. In the illustrated embodiment, the server 140 is formed usinga Sun MicroSystems SPARC computer. Suitable models include a SPARC-2, 4or 5 or similar data processing equipment. The CPU 202 operates inconjunction with instructions and data stored in the memory 204.

Each of the switch ports 208, 210, 212 is coupled to a switch of theradiotelephone system such as radiotelephone system 100 (FIG. 1). If anOMP is coupled to the switch, the switch port may be coupled to theswitch through the OMP. The switch ports serve to provide wire linecommunication with the switches. This may be two-way communication butis at least one-way communication, with the switch ports receiving datafrom the switch or the OMP. The data received by the switch ports isdata corresponding to events occurring in the radiotelephone system. Theswitch ports 208, 210, 212 receive the data as communicated and convertthe data to a form for subsequent processing by the server 140. As notedabove, the server 140 serves to identify call processing failure data inthe large amount of data received from the switches. Data unrelated tocall processing failures is discarded. Data related to or indicative ofcall processing failures is provided to one or more client ports andstored in the memory 204 as archived data. The memory may comprisesemi-conductor memory, disk memory or any other suitable storage mediumas known to those ordinarily skilled in the art.

The client ports 216, 218, 220, 222, 224 provide communication betweenthe server and associated client computers. In the preferred embodiment,one or more client computers is networked with the server 140 over alocal area network or wide area network. Communication on this wire linenetwork preferably occurs using a digital data transmission protocolwhich may be a standard protocol such as TCP/IP. Alternatively,communication may be achieved between the server and client computersusing any suitable proprietary or other protocol. The modem ports 222provide two-way communication using standard modem protocols, as knownin the art. Such modem communication may occur over a wire line, such asthe public switched telephone network (PSTN). Alternatively, such modemcommunication may occur using wireless equipment, such as cellularmodems. The wireless ports 224 provide wireless communication using anysuitable wireless data transmission protocol or conventional technique.One example is CDPD. The wireless ports 224 may include radiotransmission and reception equipment to permit radio communication witha remote, portable client.

The modem ports 222 and the wireless parts 224 allow client-servercommunication between the server 144 and portable client computers. Thisincreases the flexibility of the system 102 (FIG. 1) by permittingportable personal computers such as laptop computers to be transportedto remote sites such as a base station location for troubleshooting theradiotelephone system 100. A link may be made between the portablecomputer and a modem port 222 using a wire line, a cellular modem or awireless port using a CDPD or similar connection. At the remotelocation, call processing failure data can be accessed from server 140for real time monitoring of the system 100.

FIG. 3 is a block diagram of a client computer 300 for use in the system102 of FIG. 1. The client computer 300 includes a central processingunit (CPU) 302, a memory 304, a display 306, a keyboard 308 and acommunication port 310. The client computer in the preferred embodimentis a networked personal computer (PC) running a suitable operatingsystem such as Windows 95, Windows 98, or Windows NT 4.0, all availablefrom Microsoft Corporation. The client computer 300 may be a desktopcomputer located in an office or laboratory. In alternative embodiments,the client computer 300 may be a portable computer such as a laptop or apalmtop computer capable of remote communication with a server such asthe server 140 illustrated in FIG. 2.

CPU 302 operates in response to data and instructions in the memory 304.The display 306 may be any suitable video display terminal or otherdevice. The keyboard 308 preferably includes an alphanumerical keyboardand other manual data entry device, such as a mouse or joystick. Suchequipment is typically provided in computers which employ a graphicaluser interface, such as the Windows system.

The communication port 310 provides data communication with a serversuch as the server 140 of FIG. 2. The communication port 310 providessuitable access to a network for communicating with the server 140. Ifthe client computer 300 is a desktop computer not intended to betransported to remote facilities, the communication might be an ethernetcard or other wire line data interface. In contrast, if the clientcomputer 300 is a laptop, palmtop or other portable computer, thecommunication port 310 may include a wireless or modem interface insteadof or in addition to the wire line interface. In this manner, thecommunication port 310 allows the client computer 300 to remotely accessthe server 140 either using a dial-up modem, wireless modem or otherwireless communication.

FIG. 4, FIG. 5 and FIG. 6 are flow diagrams illustrating a method foroperating the server 140 of FIG. 2 in the system 102 of FIG. 1. Themethod steps illustrated in these flow diagrams are preferablyimplemented in one or more software routines which may be run on theserver computer 140 of FIG. 2. The computer program source codecontained in the Microfiche Appendix to this patent application containsan exemplary embodiment of such software.

In FIG. 4, the method begins at step 400. At step 402, the serverdetermines if data has been received from a switch of the radiotelephonesystem. In the illustrated embodiment, data corresponding to all eventsin the radiotelephone system are written by a switch or an OMP to aserver. The server detects the data. If data is present, the servercontinues processing at step 500 (FIG. 5). If no data are present,control proceeds to step 404. At step 404, the server determines if arequest for data has been received from a client. If so, controlproceeds to step 600 (FIG. 6). If not, control returns to step 402 andthe server remains in a loop until either data is received from a switchor a request is received from a client or other processing is required.

Referring now to FIG. 5, it shows in further detail a method ofoperating the server 140 of FIG. 2. At step 500, call data from theswitch are read by the server. If the switch is equipped with an OMP,the OMP automatically detects all events occurring within the switch andits associated base stations. The OMP makes call data related to theseevents available on a real time basis. In addition, the OMP stores thisdata for archive purposes.

At step 502, the server determines if the current call data receivedfrom the switch is call processing failure (CPF) data. If not, the datais rejected and control returns to the flow diagram of FIG. 4. In thepresent embodiment, the server filters out call data which are notrelated to call processing failures. If the call data is related to acall processing failure, at step 506, the server reads the callprocessing failure type. The call data may be of one or more specifiedtypes as will be described below. The type information may be containedin a header or other data field contained in the call data received froma switch. At step 508, a type count associated with the CPF type isupdated, for example by incrementing. At step 510, the call processingfailure data are stored in an archive. Control then returns to the flowdiagram of FIG. 4.

Referring now to FIG. 6, if the server receives a request for data froma client computer over a network, the server determines the type ofrequest received. At step 600, the server determines if the request is arequest for an update of information previously sent to the clientcomputer. If so, at step 602, the server retrieves the count dataassociated with each of the call processing failure types previouslystored (FIG. 5) and at step 604 sends the count data to the requestingclient computer.

At step 606, the server computer determines if the request from theclient computer is a request for detailed data on a particular count. Ifso, at step 608, the server computer retrieves the details for thespecified count and at step 604, sends the data to the client. At step610, the server computer determines if the request from the clientcomputer was a request for a mobile search. Such a request would includea serial number or telephone number for a particular mobile station inthe system. If so, at step 612, the server retrieves the data for theidentified mobile station and at step 604, sends the retrieved data tothe client computer over the network. At step 614, the server computerdetermines if the request from the client computer is a request tochange the switch of the radiotelephone system for which data ispresented. If so, at step 616, the data associated with the new switchis located and retrieved and at step 604 the data is sent to the client.Control then returns to the flow diagram of FIG. 4.

FIG. 7 is a flow diagram illustrating a method for operating the clientcomputer of FIG. 3 in the system of FIG. 1. An exemplary embodiment ofthe method steps shown in FIG. 7 is contained in the Microfiche Appendixincluding computer programs source code included with this patentapplication. The method begins at step 700.

At step 702, to initiate operation of the client computer, the clientcomputer retrieves count data from the server over a network. Once thecount data are retrieved, the client computer produces a display usingthe retrieved data and remains in a loop awaiting either update of thedata, step 704 or user input, step 706.

An example of the display produced by the client computer is shown inFIG. 8. As can be seen in FIG. 8, the display preferably is aWindows-type display and uses conventional Windows icons for graphicaluser interface. Pop-up menus are located behind the icons labeled File,Analog, Digital and Switches. The display 800 is divided into an upperportion 802 and a lower portion 804. In the illustrated embodiment, theupper portion 802 displays call processing data for an analog cellulartelephone system and the lower portion 804 contains call processingfailure data for a digital cellular telephone system. Identifyinginformation is arranged along the left-hand side of the upper portion802 and the lower portion 804. The identifying information includes abase station identifier (CELL), and an antenna identifier (ANT). Thecall processing failure data is sorted by the total number of failures(TOT) with the greatest number of failures listed highest in the portionof the display. Failure counts are listed across the respected columnsof the display. The failure types for the illustrated embodiment aredescribed below.

Analog failure types include the following:

Lost Call (LC). This is the most common CPF. There are three causes forthe failure. First, the base station of the cell has lost supervisoryaudio tone or SAT from the mobile station (Lost Call due to SAT timeout,LCST). Second, the mobile failed an Audit (Lost Call due to AMPS Auditfailure, LCAA). Or third, the mobile had a sudden unexplained power drop(Lost Call due to AMPS Catastrophic power drop, LCAC).

The cell begins a SAT Fade Timer when it loses SAT from the mobile. Whenthis timer expires without acquiring SAT from the mobile, the cell turnsoff the voice radio and terminates the call, creating a call processingfailure.

An audit occurs when the signal from the mobile unit becomes relativelyweak. More specifically, an audit occurs when the signal strength dropsbelow a Secondary Threshold programmed into the base station. The basestation, using blank and burst, prompts the mobile for a response andthe mobile returns a burst of ST. Failure of the cell to detect thisresponse results in the call being terminated and pegged as a Lost Call,Audit Failure. Among many potential scenarios for LC's are:

-   -   The mobile leaves the service area while a call is in progress.    -   The mobile temporarily loses signal within the service area due        to weak signal.    -   The mobile loses SAT from the system due to interference.    -   The cell loses SAT from the mobile due to interference or weak        signal.    -   The mobile unit loses its power source.    -   The mobile radio or antenna is defective.    -   The cell radio or antenna is defective.

Voice Channel Confirmation Failure (VCCF). This CPF occurs during theorigination of an inbound or outbound call. After the initial voicechannel assignment, cells are programmed to wait a few seconds on thevoice channel for the mobile. If the cell does not detect the proper SATwithin the given time frame, it will turn off the cell radio and end thecall. The signal strength must also be above the Voice ChannelConfirmation Threshold of the site. This results in a Fast Busy to thecustomer at the mobile station. The Voice Channel Confirmation Thresholdof the cell is usually programmed to allow minimal signal. The VCCF rateis usually below 1%. Possible causes of this problem include thefollowing:

-   -   Incorrect programming of the mobile Station Class Mark. Older        mobile units were only capable of 666 channel operation. If the        unit is programmed for 832 channel operation, the system will        assign channels that the mobile cannot tune to.    -   Low battery or weak mobile power source.    -   Defective mobile transmitter, low output power or bad antenna.    -   Little or no mobile SAT deviation. Also, a few mobiles have been        found to have trouble with only one particular SAT.    -   Weak coverage area within the network causes much fading.    -   Defective cell radio or antenna.

Alert Confirmation Failure (ACF). The ACF is similar to the VCCF. TheACF occurs only during origination of an inbound call to the mobile.After the page response and initial voice channel assignment, the cellwaits on the voice channel to detect ST from the mobile. Failure of thecell to detect ST within the proper time frame causes the cell to endthe process. The mobile user is usually unaware of the failure, althoughsome mobiles notify the user of a failed call attempt, (such as the“Failed Page Indicator” provided by mobile stations from Motorola, Inc.,Schaumburg, Ill.). The calling party receives two rings, then a busysignal. This is due to the fact that the call process has proceededbeyond the point where it can be switched to secondary call treatmentsuch as Voice Mail or No Page Response Recording. Common causes of thisCPF include:

-   -   Low battery or weak mobile power source.    -   Little or no mobile ST deviation.    -   Defective mobile radio or antenna.    -   Defective cell radio.    -   Weak coverage within the network. During an inbound call to the        mobile, the Page Response signal strength is not measured as the        outbound Access attempt is. If the cell receives the Page        Response, it will attempt to setup the call. This leaves open        the possibility that the mobile is too weak to be served by the        site. This is a common failure in fringe areas of the network.

Old Cell Timeout (OCT). This failure only occurs during the hand-offprocess. After the cell sends the hand-off order to the mobile itexpects to receive a burst of ST to confirm the order. An OCT occurs ifthe cell does not receive the confirmation in the proper time frame. Thecell will attempt to maintain the call, but these CPF's are oftenaccompanied by Lost Call messages. Customers experiencing large numbersof OCT's may notice more trouble as they move through the network butacceptable service while stationary. Among many causes for this are:

-   -   Incorrect programming of the mobile Station Class Mark. Older        mobile units were only capable of 666 channel operation. If the        unit is programmed for 832 channel operation, the system will        assign channels that the mobile cannot tune to.    -   Little or no mobile ST deviation.    -   Defective mobile receiver or antenna.    -   Defective cell radio.

New Cell Timeout (NCT). This only occurs during the hand-off process.After the mobile has confirmed the hand-off order on the old cell, itswitches to the new channel and transponds SAT. Failure of the new cellto detect the proper SAT in the given time frame results in a NCT. Whena NCT occurs, there has been a dropped call. This is due to the factthat the mobile has already confirmed the hand-off order on the oldchannel. The old cell mutes the audio and turns off the old radio almostimmediately upon receiving the confirmation. So, failure to detect themobile on the new channel equates to a lost call. This CPF is sometimesaccompanied by a Lost Call message. The user may experience a suddenincrease in noise as the mobile attempts to switch to the new channel,followed by a lost call. Among the causes for this problem are:

-   -   Co-channel or adjacent channel and co-SAT interference with the        old cell. During the locate process, if the potential new cell        detects the another mobile on the same channel using the same        SAT, bad hand-offs for the correct mobile will result. There is        no other ways to identify the mobile during locate other than        channel and SAT.    -   Defective mobile radio.    -   Defective cell radio.

Glare Condition Mobile Busy (GCMB). This CPF occurs during call setupattempts. The system outputs this message when it receives an accessattempt from a mobile that is already on the system. There are threemain causes for this message:

-   -   Co-setup channel and co-digital control channel (DCC)        interference. This failure occurs if two cells of the system are        using the same setup channel and there is interference between        them. Both cells detect mobiles trying to access the setup        channel. In this scenario, the GCMB is usually accompanied by a        VCCF on the other site.    -   Fraud. GCMB's will result if a mobile unit has been cloned and        one user attempts access while another unit is active.    -   Series One Cell Sites will output GCMB messages if the user        attempts access immediately after ending a call. Rapidly        repeated access attempts achieve the same result. The older cell        sites are relatively slow in “tearing down” the old call.

Call Setup Timeout (CST) or occurs when a cell site does not respond toa call setup order for the indicated voice radio. The call setup isaborted. A call setup timeout indicates a problem with the data links.

Call Shutdown (CS) occurs when the cell site cannot turn off theindicated radio after an internal error shuts down the call. Possiblesources of this problem include baseband board or transceiver for SeriesI cell sites and radio channel unit for Series II cell sites.

Alert Confirmation Failure (ACF) occurs when a mobile unit fails torespond to the alert order sent to it on the indicated voice radiowithin the time allowed. The mobile unit normally responds to an alertorder with a signaling tone (ST) on the assigned voice channel,confirming reception of the order.

Forced Release Time (FRT) out occurs when the cell site did not respondafter a forced release order was sent for the indicated radio. As aresult, the call was aborted. A forced release timeout indicates aproblem with the data links.

New Cell Timeout (NCT) and Old Cell Timeout (OCT) occur during handoffof radio communication between a mobile station and two base stations inthe system.

Transmitter Activation Failure (TAF) occurs when the cell site could notturn on the indicated voice radio.

Digital call processing failures include the following which weredescribed above:

ACF or Alert Confirmation Failure, CS or Call Shutdown, CST or CallSetup Timeout, FRT or Forced Release Timeout, GCMB or Glare Condition,Original Mobile Is Busy, and LC or Lost Call. In addition, digital callprocessing failures include the following:

CDMA Channel Activation Failure (CAF) occurs if the first attempt toactive the first channel element failed, there were no free channelelements available to attempt a second activation.

CDMA CE/SH Channel Protocol Failure (CHEF) occurs when lacking ofcontinuity has occurred in the protocol between the channel element atthe cell and the speech handler channel at the switch.

CDMA Failure to Establish CE/SH Channel Protocol (FECP) occurs as aresult of during call setup, the cell indicated that it could notestablish communication with the speech handler channel.

Release Confirmation Failure (RCF) occurs during hard handoff from CDMAto AMPS system.

Setup Channel Glare (SCG) occurs during a mobile unit attempted tooriginate a call, and the single origination is reported by multiplecells.

CDMA Traffic Channel Confirmation Failure (TCCF) occurs when a callsetup, the cell has indicated to the ECPC that the mobile has notresponded properly when bringing the mobile to the traffic channel, allresources for the call have been cleared by both the cell and theswitch.

By interacting with the display illustrated in FIG. 8, a user of aclient computer may view the display data to permit troubleshooting inthe radiotelephone system. Preferably, the software operating on theclient computer permits mouse click entries and shortcut keys to changethe display of the call processing failure data. These are generallyconsistent with the Windows user interface. For example, in response touse of a mouse to double-click a number in the display 800, the softwarepresents another window displaying detailed data for that callprocessing failure. FIG. 9 illustrates a detailed display of an analogcall processing failure. The detailed data include the telephone numberof the mobile station involved in the failed call, the electronic serialnumber of the mobile station, time of the failure and failure type. FIG.9 shows similar detailed data for a digital call processing failure. Asanother example, a mobile search may be performed by entering a mouseclick on the displayed phone number or by manually typing in the phonenumber of the desired mobile station. As yet another example, callprocessing failure data for different switches can be displayed byactivating the pop-up menu behind the switches icon at the top of thedisplay 800.

Referring again to FIG. 7, in response to a detected user input at step706, at step 708 the client computer determines if the user input is arequest for count data. If so, at step 710, a request is sent to theserver. At step 712, the requested data are received and at step 714,the requested data are displayed. Control then returns to step 704. Ifthe user input did not correspond to a request for count data, at step716, the client computer determines if the user input corresponds to arequest for a mobile search. If so, step 710, 712 and 714 are repeatedto obtain the desired information from the server.

If the user input did not correspond to a request for a mobile search,at step 718, the client computer determines if the user inputcorresponds to a request to change the switch for which data iscurrently displayed. If so, steps 710, 712 and 714 are repeated toobtain the desired data and control returns to step 704.

At step 720, the client computer determines if the user input is arequest for sort options. If so, at step 724, the client computerreceives the input specifying sort option required by the user. At step726, the display is updated and control then returns to step 704.Lastly, at step 728, the client computer determines if the user hasrequested other operations. These operations can include, for example,printing the display 800, saving the current data to a file exiting theprogram and so on. In response to the user input, 724, the display isupdated appropriately and control returns to step 704.

From the foregoing, it can be seen that the present embodiment providesan improved method and apparatus for monitoring call processing failuredata in a radiotelephone system. The embodiment illustrated herein is aclient-server system linked over a network. Client computers mayportable and access the network remotely using a wire line modem orwireless link. Data corresponding to call processing failures arepresented in summary form and sorted according to user requirements. Aconvenient and widely used interface such as Windows is provided topermit easy user access to the call processing failure data. Through useof mouse clicks and shortcut keys, sorting may be changed and detailedinformation on call processing failure counts may be accessed. Theconnection and cooperation between the client and server are invisibleto the user of the client computer. Access to data obtained and storedat the server using a portable client computer allows error diagnosisand troubleshooting in the field.

While a particular embodiment of the present invention has been shownand described, modifications may be made. For example, the system may beopened in conjunction with radiotelephone systems which do not use anOMP with a switch. Other functions and user interface features may beprovided as well. It is therefore intended in the appended claims tocover all such changes and modifications which follow in the true spiritand scope of the invention.

1. A method for the real-time collection of call processing failures ina radiotelephone network comprising: receiving call processing failuredata from a plurality of switches; analyzing the call processing failuredata at a server; determining the call processing failure data present;assigning the call processing failure data to one of a plurality offailure types; determining the one of a plurality of call processingfailure type is one of an analog call processing failure and a digitalcall processing failure; incrementing a count for the one of a pluralityof failure types; storing the failure type and the count for the one ofa plurality of failure types; troubleshooting the one of a plurality offailure types; and transmitting to at least one client thetroubleshooting information for the call processing failure data basedon the one of a plurality of failure types.
 2. The method of claim 1wherein the one of a plurality of failure types comprises an analog callprocessing failure which further comprises one of a lost call failure, avoice channel confirmation failure, an alert confirmation failure, a oldcell timeout failure, a new cell timeout failure, a glare conditionmobile busy failure, a call setup timeout failure, a call shutdownfailure, a alert confirmation failure, a forced release time failure, anew cell timeout and old cell timeout failure, and a transmitteractivation failure.
 3. The method of claim 1 wherein the one of aplurality of failure types comprises a digital call processing failurewhich further comprises one of a lost call failure, an alertconfirmation failure, a glare condition mobile busy failure, a callsetup timeout failure, a call shutdown failure, a forced release timefailure, a code division multiple access (“CDMA”) channel activationfailure, CDMA channel element, speech handler (“CE/SH”) Channel ProtocolFailure, a CDMA failure to establish CE/SH channel protocol, a releaseconfirmation failure, a setup channel glare failure, and a CDMA trafficchannel confirmation failure.
 4. A computer readable medium havingcomputer executable software code stored thereon for processing callprocessing failure data for a radiotelephone system, the computerreadable program code comprising: a first computer readable program codeconfigured for receiving call processing failure data from a pluralityof switches; a second computer readable program code configured foranalyzing the call processing failure data at a server; a third computerreadable program code configured for determining the call processingfailure data present; a fourth computer readable program code configuredfor assigning the call processing failure data to one of a plurality offailure types; a fifth computer readable program code configured fordetermining the one of a plurality of failure types is one of an analogcall processing failure and a digital call processing failure; a sixthcomputer readable program code configured for incrementing a count forthe one of a plurality of failure types; an seventh computer readableprogram code configured for storing the one of a plurality of a failuretypes and the count for the one of a plurality of failure types; aeighth computer readable program code configured for troubleshooting theone of a plurality of failure types; and a ninth computer readableprogram code configured for transmitting to at least one client thetroubleshooting information for the call processing failure data basedon the one of a plurality of failure types.
 5. The computer readablemedium having computer executable software code stored thereon forprocessing call processing failure data for a radiotelephone system ofclaim 4 wherein the one of a plurality of failure types comprises ananalog call processing failure which further comprises a computerreadable program code configured to determine whether the analog callprocessing failure comprises one of a lost call failure, a voice channelconfirmation failure, an alert confirmation failure, a old cell timeoutfailure, a new cell timeout failure, a glare condition mobile busyfailure, a call setup timeout failure, a call shutdown failure, an alertconfirmation failure, a forced release time failure, a new cell timeoutand old cell timeout failure, and a transmitter activation failure. 6.The computer readable medium having computer executable software codestored thereon for processing call processing failure data for aradiotelephone system of claim 4 wherein the one of a plurality offailure types comprises a digital call processing failure which furthercomprises a computer readable program code configured to one of a lostcall failure, an alert confirmation failure, a glare condition mobilebusy failure, a call setup timeout failure, a call shutdown failure, aforced release time failure, a CDMA channel activation failure, CDMACE/SH Channel Protocol Failure, a CDMA failure to establish CE/SHchannel protocol, a release confirmation failure, a setup channel glarefailure, and a CDMA traffic channel confirmation failure.
 7. A systemfor monitoring call processing failures in a radiotelephone network, thesystem comprising: a server coupled with the radiotelephone network andconfigured to receive call processing failure data from a plurality ofswitches; the server further configured to analyze the call processingfailure; the server further configured to determine the call processingfailure data present; the server further configured to assign the callprocessing failure data to one of a plurality of failure types; theserver further configured to determine the one of a plurality of failuretypes comprises one of an analog call processing failure and a digitalcall processing failure; the server further configured to increment acount for the one of a plurality of failure types; the server furtherconfigured to store the one of a plurality of failure types and thecount for the one of a plurality of failure types; the server furtherconfigured to troubleshoot the one of a plurality of failure types; andthe server further configured to transmit to at least one client thetroubleshooting information for the call processing failure data basedon the one of a plurality of failure types.
 8. The system of claim 7wherein the server is further configured to determine whether the analogcall processing failure comprises one of a lost call failure, a voicechannel confirmation failure, an alert confirmation failure, a old celltimeout failure, a new cell timeout failure, a glare condition mobilebusy failure, a call setup timeout failure, a call shutdown failure, analert confirmation failure, a forced release time failure, a new celltimeout and old cell timeout failure, and a transmitter activationfailure.
 9. The system of claim 7 wherein the server is furtherconfigured to determine whether the digital call processing failurecomprises one of a lost call failure, an alert confirmation failure, aglare condition mobile busy failure, a call setup timeout failure, acall shutdown failure, a forced release time failure, a CDMA channelactivation failure, CDMA CE/SH Channel Protocol Failure, a CDMA failureto establish CE/SH channel protocol, a release confirmation failure, asetup channel glare failure, and a CDMA traffic channel confirmationfailure.
 10. The system of claim 7 wherein at least one client comprisesa portable computer configured to remotely access the server for displayand analysis of the call processing failure data.
 11. The system ofclaim 10 wherein the plurality of clients are configured to selectivelydisplay both the real time call processing failure data and the archiveddata.
 12. The system of claim 7 further comprising a local area networkcoupling the server and the plurality of clients.
 13. The system ofclaim 12 wherein the local area network is an Ethernet network.
 14. Thesystem of claim 12 wherein each client of the plurality of clientscomprises a personal computer.